The Table service in Windows Azure provides highly reliable, structured
storage at scale. You can use Azure’s Table service in place of a
traditional database to store all your data. Azure’s Table service allows
you to perform typical Create, Read, Update, Delete (CRUD) operations to
manage your data. You don’t have to install any software on your virtual
machines, or even run extra virtual machines, since everything is managed
by Windows Azure internally.
Note: Internally, the Azure Table service and the rest of the Windows
Azure storage services run on the fabric, and draw the same benefits
from the fabric as customer applications do.
The Table service is designed to minimize several problems that
exist with traditional data management. It is highly scalable—users can
store billions of entities (rows) if they choose to. It doesn’t have a
strict predefined schema like a typical relational database management
system (RDBMS), and each row can have a different number (or different
types) of properties. The service provides explicit control over how the
data is partitioned, so users can choose a partitioning scheme that
provides the best performance. However, it doesn’t provide any relational
features: you cannot enforce foreign key constraints, nor can you have
queries that span multiple tables using joins.
But it does provide a query language with an HTTP REST-based API
that enables you to create, modify, and query data. This REST API is compatible with Microsoft’s ADO.NET Data
Services (part of .NET 3.5 SP1), which means you can make use of Language
Integrated Query (LINQ) and other cool features when writing .NET code.
Since it is a REST API, any language/programming environment can access
it.
Queries use the partitioning system to retrieve data with high
performance without needing tuning from the user. Unlike other distributed
storage systems, the Azure Table service is always
consistent—any changes you make are instantly
visible, and there is no propagation delay.
Azure’s Table service is designed to be an adjunct to RDBMS services
such as SQL, rather than a replacement. There’ll be scenarios in which you
need traditional database systems either hosted on-premises or hosted in
the cloud. Later in this chapter, you’ll learn about the difference
between Azure tables and SQL Services, and how to choose between the two
based on your needs.
1. Core Concepts
Azure’s Table service incorporates a few top-level
concepts:
Figure 1 shows
how these concepts relate to each other.
1.1. Understanding tables
A table is a container for a related
set of data. Tables are created under a storage account, and one storage
account can have any number of tables. Authentication is performed at
the storage account level, and you use the same authentication
mechanism that you use with the other storage services. Tables are
also the unit of querying—queries cannot span multiple tables.
A query against a table is through an HTTP GET against a URL and is formatted as
http://<StorageAccount>.table.core.windows.net/<TableName>?filter=<Query>.
1.2. Understanding entities
Data is stored in tables in the form of
entities. You can think of an entity as a row in
normal database terms. A table can literally have billions of
entities, if necessary. Entities are also the unit of read and write
access. A successful query returns a set of entities. When you write
changes back to the service, each entity is atomically written—you won’t see a situation where
certain parts of the entity were updated with a conflicting write. You can also specify
concurrency at the entity level. You could choose to have a model
where, in the case of multiple writers, only the first could succeed,
or only the last could succeed.
Entities have two special properties: RowKey and PartitionKey. This controls an important
aspect of Azure tables: partitioning. You’ll
learn about this in detail later in this chapter. When put together,
these form the primary key of the entity.
1.3. Understanding properties
Properties are the equivalent of columns—they are an individual
category of data in a table. An entity can have up to 255 properties.
Properties do not have a fixed schema—two entities within the same
table can have a different number or different types of
properties.
Each property has a name, a type, and a value. The various
types available in Azure tables are String (up to 64 KB), Binary (up to
64 KB), Bool, DateTime, GUID, Int, Int64, and Double.
1.4. Correlating to database terminology
It is sometimes tricky to keep track of the terminology,
so Table 1 lists some familiar
database terms and their rough equivalents in Azure’s Table service.
Table 10-2 lists the sizes and limits of the core resources and
types.
Table 1. Lingo map
| Database
term | Azure Table service
term |
|---|
| Table | Table |
| Row | Entity |
| Column | Property |
| Shard/partition | Partition |
| Primary
key | PartitionKey + RowKey |
Table 2. Sizes and limits
| Resource/type | Size/range/limit |
|---|
| PartitionKey | Up to 64
KB |
| RowKey (String) | Up to 64
KB |
| String | UTF-16, up to 64
KB |
| Bool | True/False |
| DateTime | 8 bytes, ranging from
1/1/1600 to 12/31/9999 |
| GUID | 16 bytes |
| Int | 32 bits |
| Long | 64 bits |
| Double | 64 bytes |
| Entity | 1 MB |
| Number of properties in
an entity | 255 + RowKey + PartitionKey |
| Property
name | 255
characters |
| Maximum entities
returned from a single query | 1,000 |
| Number of
tables | No limit |
| Number of
entities | No limit |
| Combined size of
entity | 1 MB (including the
property names) |
| Total table
size | No limit (but a storage
account is limited to 100 TB) |
